Electronic devices, such as servers and personal computers, store system settings by way of a non-volatile random access memory (NVRAM) and incorporate a battery power source to retain the system settings. NVRAMs are typically implemented using static random access memory (SRAM) integrated circuits (ICs) or chips that comprise complementary metal oxide semiconductor (CMOS) transistors or bipolar junction transistors (BJTs). However, electronic devices with NVRAMs are susceptible to boot failures when being powered on. For example, during boot-up, an electronic device may read unexpected data values from the SRAM or find a boot block corruption, which can lead to a failure to boot the operating system of the electronic device.
One of the main contributing factors to boot failures is corrupted SRAM memory cells in the SRAM. For example, an SRAM IC or chip may include an array of SRAM memory cells (e.g., six-transistor memory cells), each representing a bit and having cross-coupled inverters and access transistors. Each of the inverters drives one of two state nodes. When a SRAM memory cell is not powered, both of the state nodes are held at an unstable state, as the state nodes are both discharged. When power is applied, the two state nodes of each SRAM memory cell should each transition to one of the two stable states “0” or “1”. However, when the electronic device is powered on, the two state nodes of one or more SRAM memory cells may remain in the unstable state, or transition to the wrong stable state, for example, due to noises (e.g., parasitic electron charges) in the SRAM memory cells. As a result, the battery-backed SRAM content is placed into a stochastic state (e.g., corrupt or hung), which prevents the main logic board (e.g., motherboard) of the electronic device from performing a normal boot-up sequence. In addition, boot failures may be attributed to other factors such as Real-Time Clock (RTC) latch-up and battery power source failure.
For a long time, research and development (R&D), product engineers, and technicians have dealt with this issue of the main logic board (MLB) not powering up even though everything looked right: AC power would be applied, auxiliary (AUX) or standby power would be present, but the MLB would not boot up the system. This occurs in a fraction of systems, making it unnoticeable by typical end users. However, it is noticeable to someone tasked with testing MLBs ranging from prototype, through pilot, and into production on a day-to-day basis. Conventionally, one way of repairing the problem of corrupt SRAM memory cells or RTC lock-up, would require a person to remove all power, remove the battery which supports the SRAM, reinstall the battery, and most of the time the electronic device would power up completely as normal and never experience the problem again. However, this process of repairing the problem is a very time consuming one, especially in large scale server implementations or cases where the computers are not readily accessible. In addressing this issue, many companies or users must resort to tech service calls which could cost companies or users hundreds of dollars per affected system.
Thus, there is a need in the art for cost effective and efficient ways to prevent and/or recover from hoot failures.